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Acerca de este documento 


Este documento constituye una continuación de la Guía Cubana de Migración a Software Libre 
publicada en el año 2008. Basados en las experiencias adquiridas durante la migración de 
disímiles organizaciones, tanto en Cuba como en el extranjero, así como en la evolución de las 
Tecnologías de la Información y las Comunicaciones (TICs), los autores de este documento 
hemos querido reflejar aquellos elementos que consideramos importantes a tener en cuenta 
para llevar a cabo un proceso exitoso de migración a aplicaciones de software libre y código 
abierto. 


Las buenas prácticas expresadas en este documento han sido probadas satisfactoriamente 
tanto en entidades nacionales como en empresas privadas e instituciones del sector público en 


el extranjero. 


Este documento, como su nombre lo indica, no constituye en lo absoluto un procedimiento 
estricto, solo pretende socializar las buenas prácticas identificadas en los escenarios de 
actuación de sus autores. Por lo que recomendamos analizarla y adecuarla al entorno de cada 


organización. 
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Introducción 


Introducción 


Ningún país debería estar sometido tecnológicamente a otro, el dominio de las TICs por 
parte de las grandes empresas, crea cada vez más dependencia tecnológica a los países 
consumidores de las mismas, en ocasiones estos ignoran los problemas que tal falta de 
soberanía puede acarrear con el paso del tiempo. Entre los ejemplos inolvidables por 
quienes lo sufrieron resultan la explosión del gaseoducto soviético en el verano de 1982, los 
sucesos ocurridos en Petróleos de Venezuela S.A. durante el golpe de estado en la 
República Bolivariana de Venezuela en el 2002 y el gusano Stuxnet cuyo objetivo era 


sabotear el programa nuclear iraní. 


Por causas como estas, instituciones, organizaciones y países han comenzado a transitar a 
un nuevo estado denominado: “soberanía tecnológica”. Este se caracteriza por la posibilidad 
que tiene el país de desarrollarse de forma autónoma en este campo, teniendo total 
capacidad de decisión sobre las tecnologías y la forma en que se desarrollan y usan las 


mismas. 


Cuba no está ajena a este proceso, a partir del 2004, el país decide emprender la migración 


a plataformas de Código Abierto, creando para la ejecución de la misma cuatro grupos: 


Figura 1: Grupos para la migración a plataformas de Código Abierto en Cuba 


Cada grupo tiene funciones bien definidas, dirigidas por el grupo ejecutivo nacional para la 
migración a Código Abierto que lo organiza el Ministerio de las Comunicaciones (MINCOM). 


Página 1 de 57 


BUENAS PRÁCTICAS PARA LA MIGRACIÓN A CÓDIGO ABIERTO 


Capítulo 1: La migración a Software Libre y Código Abierto 


Capítulo 1: La migración a Software Libre y Código Abierto 


Una migración a tecnologías de software libre y código abierto puede definirse como: "Un 
proceso ordenado en el cual se sustituye, parcial o totalmente, el software existente en la 
organización por alternativas liberadas bajo licencias libres o de código abierto. Es 


recomendado incluir la adopción de estándares abiertos para la documentación.” 


Dicho proceso afecta todas las estructuras y personas dentro de la institución en la cual se 
ejecuta, provocando desconfianza y resistencia al cambio en las personas involucradas en 
el mismo. Normalmente, sus principales promotores son personas con un alto dominio 
técnico, que se dedican a asegurar cada uno de los detalles tecnológicos obviando el 
impacto en los recursos humanos, lo que aumenta sensiblemente las posibilidades de 


fracaso de la migración. 


Para aumentar las posibilidades de éxito de una migración a tecnologías de software libre y 
código abierto es necesario tener en cuenta que esta se divide en dos componentes 


fundamentales: migración social y migración tecnológica. 


Migración social: las personas son el centro de la migración 


Las inversiones en marketing de las grandes compañías proveedoras de software y su 
actividad comercial han generado un efecto interesante en los usuarios de computadoras. 
Han logrado crear una cultura de nombres para sus programas que ha eclipsado el nombre 
de la marca de las aplicaciones similares que les hacen competencia. Muchas personas no 
reconocen lo que es un procesador de textos o un editor de presentaciones, para ellos 


existe Microsoft Word o PowerPoint. 


Cuando un usuario adquiere un ordenador, por lo general, el sistema operativo instalado es 
MS Windows, de manera que en algunos casos, no conocen la marca de su propia 
computadora, que para ellos es Windows. La compenetración existente entre los usuarios y 
el sistema operativo de Microsoft es tan fuerte, que para lograr que acepten el uso de una 
tecnología diferente hay que realizar un trabajo profundo de motivación, sensibilización y 


atención personalizada. 
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Durante una migración a FOSS* el usuario involucrado transita por diferentes estados, como 
puede observarse en la Figura 2 [1]. El éxito de la migración se medirá por la rapidez y 


grado con que los usuarios pasen del estado de insatisfacción y rechazo a la aceptación de 


la migración. 
4 . .o . . 
Satisfacción, productividad 
Aceptación 
2 
o Insatisfacción 
Sy 
o 
D 
Lo] 
112) 
3 > Exploración 
E A 
a Rechazo 
es e 
e Peligro, posibilidad de fallo 
>» 


Tiempo 
Figura 2: Estados por los que pasa el usuario durante el proceso de 


migración. 


Se puede concluir entonces que la migración social es cuando en el proceso las personas 
son sometidas a un cambio en su forma de pensar, rompiendo la cultura de fidelización a los 
programas privativos provocada por la costumbre y adaptándose a la filosofía asociada al 


movimiento de software libre y código abierto. 


Migración técnica 


La migración técnica es el componente relacionado con el cambio de la tecnología. Su 
objetivo no es desterrar el software privativo de la entidad, sino sustituir aquellos programas 
que realmente puedan ser cambiados sin afectar sensiblemente el funcionamiento de la 


institución. No es una meta en sí misma, sino un camino para mejorar la productividad, 


1 FOSS: Siglas en inglés de Free Open Source Software (Software libre o de fuentes abiertas) 
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reducir los costos, lograr soberanía e independencia tecnológica, crear conocimiento y/o 


modelos nuevos de negocios. 


Uno de los principales objetivos de la migración técnica es garantizar la compatibilidad entre 
los programas existentes y sus alternativas por lo que es estrictamente necesario garantizar 
el funcionamiento del ecosistema tecnológico de la entidad durante todo el tiempo que dure 
la migración. De esta manera se podrá probar cada una de las aplicaciones que sustenten 


los procesos de negocio de la institución en ambas alternativas. 


Generalmente los programas de código abierto cumplen con los estándares internacionales 
establecidos, característica, que no siempre es compartida por las aplicaciones privativas, lo 
que dificulta el logro de la compatibilidad deseada. Por ejemplo, la suite Corel Draw, utiliza 
un formato no estandarizado (CDR) para almacenar sus datos, mientras Inkscape (una de 
sus alternativas libres) emplea el formato SVG, descrito entre los estándares ISO. 


Para la correcta ejecución de un proceso de migración a FOSS se recomienda utilizar el 
orden descrito en la Figura 3. 


o 


Figura 3: Orden de ejecución de la migración 


El orden recomendado responde a varios criterios: 


1. Los servicios telemáticos ofrecidos sobre software privativo utilizan en algunos casos 


Página 4 de 57 


BUENAS PRÁCTICAS PARA LA MIGRACIÓN A CÓDIGO ABIERTO 


Capítulo 1: La migración a Software Libre y Código Abierto 


protocolos no soportados por las herramientas libres existentes, por lo que si 
inicialmente se instalan aplicaciones libres, al tratar de acceder desde ellas a 
servicios disponibles en software privativo pueden existir incompatibilidades y no 


obtener los resultados esperados. 


2. Los administradores de redes son por lo general en las pequeñas y medianas 
empresas quienes gestionan el soporte técnico en la institución. Ellos deben ser los 
primeros en migrar y aprender a usar los sistemas libres, lo que contribuye a eliminar 


una de las barreras de un proceso de migración: “el miedo a perder el poder” [2]. 


3. Usar las aplicaciones libres sobre el sistema operativo privativo existente permite que 
los usuarios aprendan las nuevas herramientas de software sobre un entorno ya 
conocido, provocando que el cambio de sistema operativo sea menos traumático en 


el futuro. 


Clasificación de las instituciones de acuerdo al nivel de migración 


La migración puede no ejecutarse sobre todas las estaciones de trabajo. Para clasificar las 
instituciones de acuerdo al grado de uso de FOSS en sus estaciones se definen dos 
criterios: 


. Migración completa: resulta de la combinación de migrar tanto los servidores como 
las computadoras de los usuarios. La planificación de este tipo de migración tiene 
que garantizar que los clientes no queden en ningún momento sin acceso a los 
servicios proporcionados por los servidores. Para ello, se suele realizar en primer 
lugar la migración total o parcial de los servidores y, a continuación, la migración de 


las máquinas clientes. 


. Migración parcial: resulta de la combinación de migrar sólo una parte de los 
servidores o una parte de los clientes, de manera que continúa existiendo en la 
institución máquinas basadas en software privativo. Un escenario habitual es aquél 
en el cual, en el mismo sistema, se encuentran clientes basados en software libre y 


clientes basados en software privativo, cuya configuración dependerá de las 
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necesidades o preferencias de los usuarios finales. 


Cuando en una institución no se realiza la migración del 100% de los sistemas informáticos 
se ha realizado una migración parcial a software de fuentes abiertas. Este es el caso más 


común de migraciones. 


Roles involucrados en el proyecto de migración 


Jefe del equipo de migración 


Es el responsable de dirigir el proyecto de migración, por lo que debe velar por su correcta 
planificación, ejecución y cierre. Será quien tome las decisiones críticas del proyecto y 
solucione las diferencias que surjan entre los miembros del equipo. Su principal trabajo es 
remover los impedimentos, definir, y gestionar los riesgos que puedan presentarse en el 


desarrollo de la migración. 

Características, conocimientos y habilidades requeridas: 
+ Conocimientos y habilidades de gestión de proyectos. 
+ Buenas habilidades de comunicación y solución de conflictos. 
+ Conocimientos básicos de administración de servicios de red. 


+ Dominio de las tecnologías de software libre y código abierto más populares. 


Especialista de capacitación 


Es el responsable de la ejecución de las actividades de entrenamiento y formación del 
personal dentro del proyecto de migración. El especialista de capacitación debe trazar y 
velar por la correcta ejecución del entrenamiento. Su trabajo no se reduce solamente a dar 
clases o brindar conferencias sobre los diferentes programas de software que serán 
utilizados sino que también debe brindar atención individual a cada uno de los usuarios que 


reciben las acciones de formación. 
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Características, conocimientos y habilidades requeridas: 


+ Buenas habilidades de comunicación. 
. Paciencia, empatía y amabilidad en su trabajo de cara a los usuarios de la migración. 
+ Excelente conocimientos de las tecnologías utilizadas en el proyecto. 


+ Experiencia como profesor sería deseable. 


Especialista de soporte técnico 


Responsables de solucionar todos los problemas técnicos que puedan surgir durante la 
ejecución del proyecto de migración. Deben poseer conocimientos avanzados de GNU/Linux 
y administración de servicios telemáticos de manera que sean capaces de dar respuesta a 
todas las inquietudes, falsas alarmas y problemas que encuentren los usuarios finales 
involucrados en el proyecto. Entre sus funciones estará documentar cada una de las 
incidencias encontradas así como la solución aplicada, buscando enriquecer la Base de 


Conocimientos del proyecto y las Preguntas Frecuentes (FAQ). 
Características, conocimientos y habilidades requeridas: 
+ Buenas habilidades de comunicación. 
». Paciencia, empatía y amabilidad en su trabajo de cara a los usuarios de la migración. 
+ Excelentes conocimientos de las tecnologías utilizadas en el proyecto. 
+ Conocimientos avanzados en la administración de servicios telemáticos. 


+ Habilidades de desarrollo de software en entornos de software libre y código abierto 
serían una ventaja. 
Especialista relaciones humanas 


Es responsable de la mayor parte de las actividades de diagnóstico y evaluación de las 
actitudes y comportamientos de los usuarios involucrados en el proyecto de migración. Debe 


ser capaz de identificar las personas más resistentes al cambio de tecnologías así como 
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aquellas que pueden funcionar como facilitadores de la migración. Es el rol encargado de 
monitorear el estado de ánimo de los usuarios con respecto al proyecto y medir su nivel de 
satisfacción con respecto a las nuevas tecnologías y el trabajo del equipo de migración. 
Entre otras obligaciones debe participar en la realización del análisis de factibilidad 


económica de la migración. 


Características, conocimientos y habilidades requeridas: 


+ Buenas habilidades de comunicación. 
+ Paciencia, empatía y amabilidad en su trabajo de cara a los usuarios de la migración. 
+ Experiencia en la creación y aplicación de encuestas, cuestionarios y otras formas de 


recopilación de información. 
Especialista en servicios telemáticos 


Responsable de planificar, diseñar y ejecutar la migración de los servicios telemáticos de la 
institución. Debe ser capaz de seleccionar la mejor variante para la migración de los 
servidores preferentemente de forma transparente a los usuarios así como realizar la 
migración de los datos existentes a la nueva infraestructura de servicios minimizando la 
pérdida de información. Debe garantizar además la seguridad informática de la solución de 


servicios propuesta. 


Características, conocimientos y habilidades requeridas: 


+ Buenas habilidades de comunicación. 

+ Conocimientos avanzados de administración de servicios telemáticos. 

+ Conocimientos avanzados de seguridad informática. 

* Habilidades en la instalación y configuración de sistemas operativos GNU/Linux. 

+ Habilidades de desarrollo de software en entornos de software libre y código abierto 


serían una ventaja. 
Especialista en migración. 


Es un rol de propósito general cuya principal responsabilidad será el diseño, desarrollo, y 


despliegue de la solución a utilizar en la migración de las estaciones de escritorio de la 
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institución. Debe ser capaz de identificar las aplicaciones más adecuadas para el entorno de 
la institución así como las diferentes configuraciones que pueden minimizar los efectos de la 
resistencia al cambio de los usuarios. Una de sus actividades fundamentales es la atención 
individualizada a los usuarios durante la migración de las estaciones de trabajo, durante la 


cual debe documentar todas las incidencias de soporte detectadas. 
Características, conocimientos y habilidades requeridas: 
+ Buenas habilidades de comunicación. 
» Paciencia, empatía y amabilidad en su trabajo de cara a los usuarios de la migración. 


+ Conocimientos avanzados en la instalación y configuración de sistemas operativos 
GNU/Linux. 


+ Conocimientos avanzados en la utilización y configuración de las aplicaciones libres 
y de código abierto más populares (Suites Ofimáticas, navegadores web, 


reproductores multimedia, clientes de correo electrónico y mensajería etc.). 
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Capítulo 2: Consultoría en migración a Código Abierto 


Planificar el diagnóstico 


Consiste en planificar todas las actividades que serán realizadas durante el diagnóstico a la 
entidad. Su principal entregable es un cronograma que será aprobado por el director de la 


institución involucrada y el equipo de migración. 


Dicho cronograma constituye un acuerdo entre los proveedores del servicio de migración y 
el solicitante del mismo, para ejecutar el diagnóstico inicial que definirá si es viable o no 
realizar la migración en la entidad. Su principal finalidad es documentar la fecha y duración 
de las visitas a la entidad cliente, así como planificar las posibles interrupciones que serán 


realizadas en cada departamento o área. 


Realizar inventario de hardware y software 


La calidad y el óptimo funcionamiento de los futuros sistemas libres dependerán en gran 
medida del levantamiento informático que se realice durante la etapa de diagnóstico a la 
institución. El diagnóstico de la tecnología se realizará sobre los servidores, estaciones de 


trabajo y dispositivos externos existentes. 


En el caso de las estaciones de trabajo y servidores es evaluado además de sus 
características de hardware, el software interno que los mismos poseen. La relación 
existente entre los componentes es un factor importante a tener en cuenta durante el 
diagnóstico; el proceso de migración como resultado final debe de desencadenar la menor 


cantidad de cambios posibles en aras de disminuir la resistencia al cambio. 


Diagnóstico a las estaciones de trabajo 


El diagnóstico a las estaciones de trabajo es la obtención de información útil para la 


migración sobre las mismas; persigue dos objetivos: 
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+ Obtener información sobre las aplicaciones informáticas instaladas y utilizadas en las 
computadoras de los usuarios (Ver Anexo 1: Información necesaria del software 


instalado. ,). 


+ Obtener la información de los componentes de hardware de cada estación de trabajo 


(Ver Anexo 2: Información necesario del hardware de las computadoras.) 


Tanto el proceso de levantamiento de información de hardware como de software se 
recomienda realizarlo haciendo uso de la herramienta automatizada de control de 
inventarios OCSInventory [3]. La misma recopila toda la información que se necesita, 
además de contar con otras bondades como la emisión de reportes, despliegue 
automatizado sobre dominios Windows, clientes para analizar información desde 
plataformas Microsoft Windows, MacOS, GNU/Linux y otros sistemas, entre otras útiles 


características. 


OCSInventory, al igual que otros sistemas de gestión de inventarios sólo es capaz de 
detectar las aplicaciones que están instaladas en Microsoft Windows si estas poseen sus 
datos en el registro del sistema, por lo que las aplicaciones comúnmente conocidas se 
obtendrán al ejecutar el inventario automatizado. Existe sin embargo otro conjunto de 
aplicaciones que no saldrán en el levantamiento automatizado. Es por ello que, 
independientemente de ejecutar el levantamiento automatizado de la información, se debe 
realizar un minucioso diagnóstico de las soluciones que se empleen y sean propias de la 


institución, en este grupo están: 
+ Hojas de cálculos con macros especializadas. 


+ Bases de datos personales existentes en Microsoft Access, Excel u otros sistemas 


de almacenamiento de información. 


» Aplicaciones propias desarrolladas por la institución y que sean empleadas para 


automatizar procesos específicos. 


De los casos anteriores debe recuperarse toda la información posible, que permita la 


posterior postulación de nuevas soluciones para sustituir o migrar las mismas. Resulta 
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relevante entonces obtener la información mostrada en el Anexo 3: Información necesaria 


de cada aplicación propia de la institución. 


Paralelo al inventario automatizado haciendo uso de OCSInventory, se obtendrá la 
información del hardware interno del sistema, e incluso de algunos dispositivos externos que 
estén conectados al ordenador. Aunque esta última información es útil, no será tenida en 
cuenta, a menos que se garantice que todos los dispositivos como impresoras o scanners 
estén conectados al momento de inventariar los sistemas. La información de los dispositivos 


externos se obtendrá como se detalla en la próxima sección. 


A partir de la información recuperada por OCSInventory es importante poseer los elementos 


mostrados en el Anexo 2: Información necesario del hardware de las computadoras. 


Con la información del hardware se podrá proceder a verificar la compatibilidad con 
GNU/Linux, así como comenzar a crear un sistema optimizado para dicho hardware. La 
información del software será de utilidad en la selección de las alternativas libres más 


adecuadas. 


Diagnóstico de los dispositivos externos 


El diagnóstico de los dispositivos externos comprende todos aquellos componentes que son 
conectados a una computadora. En el amplio espectro de dispositivos existentes en la 
actualidad existen muchos cuya compatibilidad está limitada a los sistemas privativos, 
debido a la inexistencia de controladores para GNU/Linux. Es por ello que la evaluación 
previa antes de migrar estos elementos es tan importante; es un elemento útil que influye en 


la viabilidad del proceso de migración. 


De cada dispositivo externo debe recopilarse la información detallada en el Anexo 4: 


Información a recopilar por cada dispositivo externo. 


Es importante tener en cuenta, que no solo deberán ser evaluados los dispositivos externos 
de la institución, si los usuarios poseen dispositivos propios como celulares, memorias USB 
o cualquier otro, también deberán ser tenidos en cuenta en aras de buscar soluciones que 


garanticen su compatibilidad con GNU/Linux; de la comodidad del usuario en el futuro nuevo 
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sistema y de las facilidades que este le brinde, dependerá en gran medida el éxito de la 


migración. 


Diagnóstico a servidores y servicios 


La migración de servidores y sus servicios como se observa en la Figura 3 es el primer paso 
en el proceso de ejecución de la migración de la tecnología. Por esta razón debe realizarse 
un diagnóstico que permita proponer las soluciones más acertadas que garanticen 


interoperabilidad tanto con sistemas privativos como libres. 


La amplia red de servicios y soluciones que existen en las instituciones está cada día más 
integrada; es común encontrarse en las empresas un servidor de directorio activo sobre 
Microsoft Windows Server 2003 y sobre el mismo autentican las computadoras de los 
usuarios, el sistema de gestión financiera y la intranet institucional. En tal caso existe una 
estrecha relación entre los sistemas y si se migra el servidor de directorio puede traer 
consigo que los usuarios no puedan acceder a sus computadoras con el usuario del 
dominio, o que dejen de ser accesibles la intranet y el sistema de gestión financiera. Es por 
esto que obtener el tejido de relaciones y dependencias entre sistemas y servicios es tan 
importante para tomar decisiones futuras en la planificación de la migración sobre cómo 


serán migrados los sistemas y en qué orden. 


Por la importancia de los servicios telemáticos, su alcance y repercusión en el negocio de la 


institución debe realizarse un profundo proceso de recopilación de información. 
Los elementos necesarios diagnosticar son: 


+ Acerca del hardware 


+ Nombre identificativo: Debe ser un nombre que identifique al servidor 
únicamente, por ejemplo, HP Proliant DL380G5, o DHCP (si solo existe uno 


físico). 


+ Procesador: Características del procesador, ejemplo: Intel Xeon Dual Core a 2.6 
Ghz, Intel Core 13 a 2.13 Ghz. 
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Memoria RAM: Características de la memoria RAM instalada, ejemplo: RAM 


DDR2 de 2Gb a 800 MHz o Memoria Ram DDR3 de 2Gb a 1066 MHz. 


Disco duro: Características del o los discos duros del servidor, ejemplo: 500 Gb 
de capacidad, con 16 mb de cache, a 7200 RPM. En caso de más de un disco 


duro y haya algún nivel de redundancia entre ellos, también debe especificarse. 


Tarjeta de red: Características de la tarjeta de red, ejemplo Broadcom Fast 


Ethernet a 1 Gbps. 


Observaciones de hardware: En este aspecto se informará de hardware 
específico instalado en cada uno de los servidores y que pudieran necesitar de 
drivers en los sistemas operativos GNU/Linux. Tal es el caso de una UPS a la 
que esté conectada el servidor, también tarjetas HBAs para el almacenamiento 
en dispositivos con este fin desde el servidor; así como demás dispositivos que 


se entienda son necesarios. 


Acerca del software: 


Sistema operativo y versión: La variante del sistema operativo desde la cual se 


desea realizar la migración, ejemplo: Windows Server 2003. 


Arquitectura del sistema operativo: La arquitectura del sistema operativo que se 
encuentra instalado en el servidor, ejemplo: arquitectura de 32 bits o arquitectura 
de 64 bits. 


Software usado para brindar servicio: Debe colocarse todo el software que se 
encuentra brindando servicios en el servidor, por ejemplo: DHCP, DNS de 
Windows Server. En los casos en que se pueda, puede especificarse la versión 
del mismo, por ejemplo: en el servicio de correo electrónico, puede especificarse 
Mdaemon 10.0.0, servicio apache 2.01, SQL Server 2000, etc. 


Relación entre servicios: Debe especificarse la relación entre los servicios. En 
varios casos, los servicios utilizan para dar acceso de autenticación a usuarios 
del Directorio Activo; los servidores de bases de datos, dan acceso a sus bases 


de datos a las aplicaciones desde determinados servidores; los servidores DHCP 
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en Ocasiones adicionan registros en las bases de datos de los servidores DNS al 
asignar una dirección IP. Toda esta red de comunicación debe quedar 


plenamente diagnosticada. 


+ Cantidad de usuarios concurrentes: Se estimará la máxima cantidad de usuarios 


O peticiones que en un momento dado usarán concurrentemente el servidor. 


+ Configuraciones específicas: Se detallarán las configuraciones específicas del 
servidor, tanto de autenticación, como de seguridad o rendimiento. Estas deben 


especificarse por servicios y de la forma más clara posible. 


Realizar análisis del negocio y los procesos de la institución 


El análisis del negocio y los procesos de la institución es una actividad crucial en el 
diagnóstico inicial de la migración. Su objetivo es obtener la información de la institución que 
será de vital importancia a la hora de evaluar la factibilidad técnica y económica de la 


misma. No puede obviar ninguno de los elementos siguientes: 
+ — Misión y visión de la institución. 
+ Cantidad de personal. 
+ Organigrama y estructura física. 
» Principales procesos de la institución (estratégicos, sustantivos y de apoyo). 


+ Relación entre los procesos de la institución y las tecnologías de software y hardware 


existentes. 


Esta información debe ser entregada al iniciar el proyecto de migración para que el equipo a 
cargo del proceso conozca sus áreas y pueda planificar el orden de realización de 


encuestas y entrevistas. 


Identificar interesados 


En el caso de una migración a tecnologías de software libre y código abierto los usuarios de 
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la organización suelen ser los de mayor impacto para el proyecto, debido a que son los que 


pueden contribuir a su avance o sabotearlo. 


La resistencia al cambio de los usuarios exige que sean considerados como interesados 
críticos aquellas personas que sean identificadas como líderes de opinión, no importa si son 
detractores o entusiastas de las tecnologías libres. No pueden dejar de identificarse y 


describirse en el registro de interesados los siguientes roles de la institución: 


+ Director de la empresa. 

+ Director o responsable del área de tecnologías y de seguridad informática. 
+ Personal del área informática y soporte técnico. 

+ Diseñadores y personal con contenido de trabajo creativo o artístico. 


Las actividades iniciales de recopilación de información pueden realizarse a través de 
aplicaciones informáticas como LimeSurvey [4], sin embargo, es crítico que exista contacto 
personal con las personas involucradas en la migración. Este proceso guarda una estrecha 
relación con el análisis del negocio y los procesos de la institución, puesto que generalmente 
ambos obtienen la información requerida para su correcta ejecución durante la misma 


entrevista o contacto con el usuario. 


Realizar el análisis de factibilidad 


Evaluación del software de escritorio 


Un elemento clave en la realización del análisis de factibilidad está asociado a la evaluación 
de las herramientas libres a usar en la institución, no siempre la herramienta libre más 
completa de su tipo es la ideal para ser desplegada y empleada, es importante dar 


respuesta a las siguientes preguntas para poder seleccionar la alternativa más adecuada: 


+ ¿Cuál es el proceso que automatizará la aplicación? 


+ ¿Cuál es el nivel de preparación y conocimientos que tienen los usuarios sobre 
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+ ¿Cuál es el nivel de dominio que posee el usuario de la herramienta privativa que 


automatiza ese proceso? 


+ ¿Está ese proceso automatizado o no? 
+ ¿Qué funcionalidades debe tener la futura aplicación a usar? 


+ ¿Cuáles son las características técnicas que dispone el hardware en el que se va a 


ejecutar la nueva aplicación? 


Las respuestas a las preguntas anteriores resultarán ser los elementos a tener en cuenta 


para seleccionar la herramienta libre adecuada. 
Se recomienda además: 


+ No usar varias herramientas que correspondan a una misma categoría (por ejemplo, 
LibreOffice Writer y Abiword), pues esto dificultaría las actividades de soporte, 


entrenamiento y muy probablemente la interoperabilidad. 


. Seleccionar preferiblemente soluciones que se ajusten e integren al entorno de 


escritorio que se seleccione. 


+ Seleccionar de todas las herramientas evaluadas, las más simples de comprender 


para el usuario y que satisfagan las respuestas de las preguntas anteriores. 


+ Siempre pensar antes de proponer la solución, en el usuario y el desarrollo del 


proceso, que es pensar en la futura productividad. 


La existencia en los sistemas GNU/Linux de múltiples alternativas a cada solución privativa, 
permite flexibilidad y da la posibilidad de seleccionar soluciones a la medida, pero a la vez 


hace compleja la tarea de selección. 


Lamentablemente, en casos muy específicos existe software que no dispone de una 


alternativa libre con las funcionalidades necesarias, o no existe una alternativa para ser 
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sustituido. Entonces se sugiere seguir el orden mostrado en la Figura 4 que ilustra las 
posibles soluciones que pueden brindarse. 


Figura 4: Orden para la selección de las posibles soluciones a implantar. 


Los pasos 1, 2 y 3 de la figura anterior permitirán reemplazar la aplicación usada por una 
alternativa libre, en cambio, los restantes pasos tienen como objetivo mantener la aplicación 
privativa en aras de garantizar la productividad y a la vez disminuir la cantidad de software 
privativo instalado en cada ordenador donde se use la solución seleccionada. 


En caso de que para alguna aplicación sea necesario implementar alguno de los pasos 4, 5 
Óó 6 de la Figura 4, entonces la migración no se realizará de manera total, sino parcialmente, 


en tal caso la institución será clasificada como migrada de forma parcial. 


La solución propuesta en el paso 5 requiere de que la institución posea recursos de altas 
prestaciones en el nodo de servicios para poder implementar una plataforma de SaaS, 
pudiera valorarse Ulteo. 


Existe un grupo de aplicaciones que ya han sido probadas y desplegadas en procesos de 
migración. La mismas son consideradas dentro del grupo de herramientas comunes o más 


usadas por los usuarios. El Anexo 5: Aplicaciones libres alternativas al software privativo 
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(Escritorio) muestra las mismas, se sugiere emplearlas en los procesos de migración que las 


necesiten. 


Evaluación del software para servidores 


De manera análoga debe realizarse la selección de las aplicaciones informáticas que 


servirán de soporte para los servicios telemáticos de la institución. La buena calidad de la 


información recopilada durante el proceso de diagnóstico es fundamental para este paso. 


Elementos de gran importancia a tener en cuenta en la selección de las alternativas para la 


migración de los servicios son: 


Conocimientos y experiencia de los administradores de red sobre el uso de las 


tecnologías libres. 


El conocimiento de los administradores de red debe ser un punto crucial a evaluar, si 
los mismos no poseen los conocimientos teóricos básicos sobre los servicios y las 
tecnologías libres, debe procederse a un proceso de entrenamiento intensivo. La 
experiencia en el uso de determinada aplicación es importante, pero no puede ser un 


punto decisivo para decidirse por una tecnología. 


Estudio constante de las tecnologías existentes. 


El Anexo 6: Aplicaciones libres alternativas al software privativo (Servidores) propone 
las soluciones que hasta al momento han sido probadas en escenarios de pequeñas 
y grandes empresas, sin embargo el desarrollo vertiginoso del software de código 
abierto y la libre competencia existente ha demostrado el rápido desarrollo de las 
aplicaciones, por lo que se debe mantener una evaluación constante de la diversidad 


de aplicaciones existentes. 


Funcionalidades utilizadas de los servicios privativos desplegados en el escenario 


origen. 


En diversas instituciones puede darse el caso que en el escenario origen existan 
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instalados servicios telemáticos de gran potencia funcional y sin embargo de las 


mismas solo se usan un reducido grupo de funcionalidades. 


La selección de la alternativa libre debe adecuarse a las necesidades de la 


institución y no a la alternativa al servicio privativo existente. 


+ Recursos de hardware disponibles. 
+ — Migrabilidad de los datos y las configuraciones. 


La herramienta alternativa propuesta debe almacenar su información en un formato 
tal que posibilite la migración de los datos existentes en la plataforma de origen hacia 
ella. Es importante tener en cuenta que muy pocas herramientas libres poseen 
herramientas de migración propias, por lo que hay buscar software de terceros que 
posibiliten la migración desde la herramienta privativa existente en el escenario 


origen hacia la libre que se desplegará. 


No se recomiendo usar más de un sistema operativo libre, pues se complejizan las tareas de 
soporte e incluso pueden surgir con las actualizaciones constantes de las aplicaciones 


incompatibilidades. 


La migración de los servicios telemáticos es una oportunidad para identificar actividades que 
pueden ser automatizadas a través de la instalación de nuevos servicios, el ejemplo más 
común es la instalación de un sistema de gestión documental para le gestión de documentos 


administrativos. 


No se deben seleccionar aplicaciones, cuyos requerimientos de operación excedan la 
capacidad de cómputo existente. De ser necesario, debe sugerirse la adquisición de 
equipamiento. 


Evaluación del hardware 


Un factor clave para evaluar la viabilidad del proceso de migración es determinar la 


compatibilidad del hardware presente con el futuro sistema libre a implantar, en la actualidad 
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los sistemas GNU/Linux son en su gran mayoría compatibles con la amplia gama de 
dispositivos existentes, sin embargo hay un grupo reducido que son claves tener en cuenta, 
pues su compatibilidad es variable en dependencia de la marca y modelo, resulta importante 
evaluar entonces por lo extendidas que están en las instituciones las impresoras, los 


scamners y los dispositivos que posibilitan la conexión a redes inalámbricas. 
Impresoras 


El proceso de certificación de impresoras es fundamental para determinar la compatibilidad 
de las mismas consultar el sitio OpenPrinting [5] en dicha web se podrá verificar el estado de 
la compatibilidad del dispositivo seleccionando por fabricante y modelo, o simplemente 
mostrando todos los modelos de un fabricante determinado. OpenPrinting clasifica la 


compatibilidad de una impresora en 5 posibles estados (Ver Tabla 1) 


Tabla 1: Estados de compatibilidad de las impresoras, según OpenPrinting.org. 


Estado Descripción 

Perfectamente Compatible perfectamente 

Mayormente La mayoría de las funcionalidades características funcionan 
correctamente. 

Parcialmente Solo algunas funcionalidades trabajan correctamente. 

Muy ligero Incompatible. 

Desconocido No se conoce la compatibilidad. 


Si una impresora determinada no es compatible mediante USB o Puerto Serie/Paralelo y 
brinda la posibilidad de ser usada como una impresora de red, entonces puede valorarse el 


uso de la misma usando esta interfaz. 


Scanners 
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La compatibilidad de los scanners con GNU/Linux debe ser comprobada a través del 
proyecto SANE (Scanner Access Now Easy) [6]. SANE ofrece 6 estados de clasificación 


para los scanners. 


Tabla 2: Estados de compatibilidad de los scanners, según Sane-Project.org. 


Estado Descripción 

Completo El escaner funciona correctamente. 

Bueno La mayoría de las funciones están disponibles. 

Básico Las funciones básicas están disponibles. 

Mínimo Solo las funciones mínimas presentan algún grado de operación. 
No soportado No está soportado. 

No probado No ha sido probado. 


Tarjetas de red inalámbricas 


Si al probar el sistema operativo GNU/Linux la tarjeta Wifi no funciona es recomendado 
revisar el estado de compatibilidad de la misma. El sitio Linux Wireless [7] ofrece un listado 
clasificado por fabricantes, tipos de interfaz y chipset en el que se puede comprobar el 
estado de compatibilidad de las mismas con los sistemas operativos libres. Dicha web 


provee 4 clasificaciones. 


Tabla 3: Estados de compatibilidad de las tarjetas Wifi, según Linux Wireless. 


Estado Descripción 


Verde Soportado correctamente. 
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Amarillo Algunos son soportado 
Rojo No soportado 
Gris No ha sido probado 


Consideraciones generales sobre el proceso de evaluación de la compatibilidad del 


hardware. 


A continuación se muestran un conjunto de pasos genéricos que se recomiendan para 


evaluar la compatibilidad de cualquier dispositivo externo con GNU/Linux. 
1. Instalar la distribución GNU/Linux con la que se desea comprobar la disponibilidad. 
2. Iniciar la sesión de usuario. 
3. Conectar y encender el dispositivo. 


4. Si funcionó listo, sino visitar el directorio de sitios de referencia (linux-drivers.org) 
desde donde se puede acceder a los diferentes portales web que permiten verificar 


la compatibilidad de los dispositivos. 
5. Si se indica que el dispositivo es compatible, buscar el drivers asociado e instalarlo. 


6. Si funcionó listo, sino instalar los diferentes drivers genéricos que puedan existir para 


dicha marca de dispositivo, e ir probándolos. 
7. Si funcionó listo, sino declarar el dispositivo como no compatible. 


Todos los procesos de evaluación de la compatibilidad de los dispositivos debe realizarse 
sobre el hardware específico que se va a certificar y con la distribución GNU/Linux que se va 


a desplegar. 
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Evaluación de las necesidades de soporte 


El soporte técnico dentro del proceso de migración a aplicaciones de código abierto es un 
proceso transversal que comienza su ejecución antes de la migración del primer sistema 
informático de la entidad; junto al entrenamiento son los dos procesos fundamentales que 
del éxito de su realización y calidad dependerán los niveles de aceptación/rechazo de los 


usuarios a la migración. 
Por la relevancia de contar con un adecuado sistema de soporte es importante: 
1. Evaluar el punto de partida existente. 
2. Definir un protocolo de atención a incidencias. 
3. Definir los mecanismos tecnológicos de apoyo. 
4. Planificar los hitos de soporte. 
Evaluar el punto de partida existente 


Las condiciones de soporte existentes en la institución en el escenario origen, el nivel de 
conocimiento de los usuarios en las tecnologías empleadas y las condiciones tecnológicas 
de la entidad para afrontar cambios en los sistemas son elementos claves a tener en cuenta 


como punto de partida. 


Debe realizarse una valoración del esquema de funcionamiento del sistema actual existente 
para el soporte y revisar si realmente cumple con los tiempos de respuesta y calidad 
necesarios. Debe revisarse en ese sentido el nivel de preparación de los especialistas de 
soporte técnico, cantidad de especialistas contra posibles incidencias que se puedan 
generar, y calidad del sistema de soporte términos de conocimiento por parte de los 


usuarios, calidad de respuesta y nivel de automatización de los procesos. 
Definir un protocolo de atención a incidencias 


Un eficiente mecanismo de atención a incidencias y su cumplimiento posibilitará disminuir 


los tiempos de respuesta ante las posibles dificultades que puedan enfrentar los usuarios. 
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Es importante en primera instancia definir niveles de prioridad en la atención a las 


incidencias identificando desde el inicio las que poseen un mayor nivel de criticidad. 


La criticidad de una incidencia estará relacionada de acuerdo con el elemento que la generó, 
entendiéndose un elemento como ciertas funcionalidades del software, equipamiento 


hardware, documentos de trabajo diario, persona o grupo de personas. 
Una incidencia se cataloga como crítica si cumple uno o varios de los siguientes principios: 
+  Lafrecuencia de uso del elemento relacionado en la entidad es grande. 
+. El elemento afecta el modelo de negocio directamente de la entidad. 
+ Genera determinado grado de paralización de los procesos de la entidad. 
» Afecta directamente a los agentes decisores (Jefes). 
+ El elemento afectado tiene un alto grado de extensión en la institución. 


A partir de los elementos anteriores se pueden clasificar las incidencias en dependencia del 


número de principios que cumplan y establecer niveles de prioridad sucesivos. 


La estrategia de soporte a implantar en la institución debe tener consigo los niveles de 
servicio, que consisten en la definición de los diferentes niveles de tratamiento que se le 
puede dar a las incidencias, pudiéndose acordar para cada nivel un grado de calidad en la 


atención a los usuarios en términos de tiempo de respuesta y de resolución de la incidencia. 
Se identifican dos niveles de soporte comunes en los procesos de migración: 


+ Problemas que no requieren desarrollos, generalmente son resolución de dudas de 


los usuarios o configuraciones específicas de las aplicaciones. 
+ Problemas que requieren desarrollos o corrección de dificultades. 


Definir los mecanismos tecnológicos de apoyo 
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Las tareas de soporte son costosas en cuanto tiempo y esfuerzo, es por ello que la 


automatización de las mismas es fundamental, se debe de definir en dependencia de las 


condiciones iniciales y del protocolo de atención a incidencias establecido las herramientas 


que servirán de apoyo al proceso de soporte en la entidad. 


Tabla 4: Tablas de herramientas para el soporte técnico. 


Categoría Ámbito Nacional (Cuba) Genérica 
NovaDesk (Soporte interno). 

Gestión de incidencias Centro de Soporte UCI GLPI 
(Soporte profesional). 
NovaDesk. GLPI 


Base de conocimientos 


Centro de Soporte UCI. 


FAQ de las distribuciones 


Gestión de inventarios de IT 


OCSInventory + GLPI. 


OCSInventory + GLPI. 


Documentación en línea 


Comunidad humanoOS. 
GUTL. 


Wiki, Sitio y Forum de la 
distribución seleccionada. 


Repositorios de aplicaciones 


Nova (http://novarepo.uci.cu) 
[Nacional] 


Nova (http://reponova.uci.cu) 
[Internacional] 


Otras 
en los 


Electrónica [Nacional]. 


distribuciones de 
GNU/Linux están disponibles 
repositorios de los 
Joven Club de Computación y 


Repositorio de 
aplicaciones de la 
distribución seleccionada. 


Centro de llamadas 


Teléfonos internos de la 
institución. 
Centro de soporte (837 3797). 


No procede 


Debe tenerse en cuenta que la implantación de cada uno de estos servicios puede traer 


consigo la adquisición/renovación de la infraestructura de hardware, por lo que se 
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recomienda buscar un balance entre el beneficio del componente de soporte y el costo de su 


implantación. 
Planificar los hitos de soporte 


La última fase en la evaluación de las necesidades de soporte consiste en la planificación de 
los principales hitos durante la ejecución de la migración, es recomendado además una 
planificación a corto plazo post-migración en la que un equipo reducido de especialistas de 


soporte acompañe a la institución por un período de tiempo establecido. 
El plan de soporte debe dejar claro como mínimo: 


+ Etapas en las que se desarrollará el soporte, con sus períodos de tiempos 


asociados. 


» Planificación de las tareas particulares de cada etapa (Instalación de sistemas, 


actualizaciones, mantenimientos, etc). 


+ Mecanismo para la recepción y manejo de las incidencias que posibilite su posterior 


clasificación e introducción en la base de conocimientos. 


». Especificación de los tiempos de respuesta de acuerdo a la criticidad y acuerdo de 


servicio. 


Evaluación de las necesidades de entrenamiento 


La actividad fundamental para lograr una migración social que llegue a todos los 
involucrados es el entrenamiento: actividad que permitirá una preparación en el uso de las 
tecnologías de Código Abierto que luego se traducirá en productividad de los usuarios en el 
manejo de las mismas. Por esta razón debe ser concebido de manera integral a través de 


una estrategia que posibilite formar a cada usuario de la institución según sus necesidades. 


La figura que se ilustra a continuación muestra las actividades que deben seguirse de 


manera general para el desarrollo del proceso de entrenamiento. 
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Figura 5: Actividades a desarrollar para el entrenamiento a los usuarios. 


La actividad 1 es desarrollada según las indicaciones establecidas en la sección: Identificar 
interesados, las restantes actividades deben estar plasmadas en la estrategia de 


entrenamiento que se elabore como resultado de este paso. 


Una vez ejecutadas todas las actividades relacionadas con la evaluación del personal y 
seleccionadas las nuevas aplicaciones que se incorporarán en la institución, es necesario 


definir los planes de entrenamiento de los usuarios. 
Planificación del entrenamiento 


La ejecución de la actividad 2 de la Figura 5 implica varias acciones que deben tenerse en 


cuenta y se detallan a continuación: 
1. Analizar la información obtenida durante el proceso de evaluación para: 


o Determinar el nivel de conocimiento de cada usuario en las herramientas que 


utilizan en la actualidad y las previstas para el futuro. 


o Definir el orden de prioridad para la participación de los usuarios en los 
cursos. (Se recomienda darle prioridad a los directivos y que los mismos 
formen parte del primer grupo en recibir la capacitación). 
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o Agrupar los usuarios en alguno de los siguientes grupos, según la actividad 
que desempeñen; esto ayudará a organizar la estrategia de capacitación. 


/Desarrolladores | Soporte técnico 


Figura 6: Clasificación de los usuarios para las actividades de entrenamiento. 


= Soporte técnico: Grupo de usuarios dentro de la institución cuya 
función es brindar soporte técnico a las infraestructuras 
(computadoras de los usuarios, servicios telemáticos, etc). En este 
grupo se incluyen los administradores de red. Sus miembros recibirán 
cursos relacionados con el manejo del sistema de soporte técnico, así 
como todos los cursos que recibirán los grupos ubicados por debajo 


en la pirámide. 


m Desarrolladores: Debido a que es común la existencia de grupos de 
desarrollo de software en ciertas instituciones, la categoría de 
desarrolladores servirá para agrupar a los usuarios afines. Los 
miembros de este grupo recibirán formación en el manejo de 
lenguajes, bibliotecas y frameworks de desarrollo libres. Además los 
cursos que reciban los que se encuentran por debajo de ellos en la 
pirámide. 
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m Instructores: En instituciones de tamaño superior a 50 personas es 
recomendable la formación de instructores. Los instructores serán 
aquellos usuarios, que posean conocimientos previos en determinada 
materia o que son entusiastas del software libre y tienen disposición y 
cualidades que les permitan ser replicadores del conocimiento. Los 
instructores deberán recibir cursos con un nivel superior al de los 
usuarios finales; la tarea fundamental de los instructores dentro de la 
migración es formar a los usuarios finales, por lo que estos deben 


formar parte de los usuarios con prioridad para la formación. 


= Usuarios finales: Todos los usuarios que no formen parte de los 
grupos mencionados anteriormente se sumarán a este. Estará 
formado fundamentalmente por secretarias, directivos, personal de 
oficinas, entre otros. Los usuarios pertenecientes a esta categoría 
recibirán los cursos más básicos. Existen además otro grupo de 
usuarios finales que recibirán entrenamiento especial en las 
herramientas específicas que emplean; ejemplo de ello son los 


diseñadores gráficos. 
2. Seleccionar y/o contratar el personal que impartirá los cursos de capacitación. 
3. Realizar los programas de clases específicos para cada actividad de formación. 
4. Aprobar los programas de clases y comenzar la realización de las clases a impartir. 


5. Revisar de forma integra programas y clases, corregirlos y aprobarlos para su 
impartición posterior. 


Las actividades de la 2 a la 5 serán ejecutadas por el ente encargado de impartir el 


entrenamiento. 
Puntos claves dentro de la planificación del entrenamiento 


La planificación debe contemplar elementos que detallen la forma en que se va a impartir el 


entrenamiento, se debe prestar particular atención a: 
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+ —Laubicación de los locales donde serán impartidos (si están definidos). 
+ La necesidad de medios para cada acción de formación que se impartirá. 


+ Las sugerencias de las condiciones que deben existir en cada local (luz, pizarra, 


proyector, TV, computadoras, sillas, etc). 


» Los horarios de cada actividad. 
+ Los usuarios que deben asistir a cada clase. 
+ Laforma en que serán informados los usuarios sobre las actividades. 


» Orientaciones generales sobre elementos que sean de cumplimiento para 


instructores — y estudiantes durante la ejecución de las actividades. 
Evaluación del proceso 


Es de gran importancia en el proceso de migración lograr que los usuarios se beneficien del 
mismo. La entrega de certificados de participación en los cursos es una acción que ayudará 
a los participantes a mejorar su currículum vítae, por lo que los mismos ven esta acción en 
su favor y les motiva la idea de ser partícipes de cursos para poder adquirir tales créditos. 


Para poder emitir certificados la capacitación del personal debe ser por tanto evaluada. 
Certificación 


Por la importancia que reviste esta actividad, la estrategia de capacitación debe explicar 
cómo va a ser ejecutada la misma, es importante contar con una entidad certificadora 


autorizada que dé validez oficial a los créditos. 


Desarrollar el informe de diagnóstico 


Constituye el hito final de la consultoría y consiste en plasmar toda la información obtenida 
durante la ejecución de los procesos de diagnóstico y análisis de factibilidad, es un informe 


dirigido a los directivos de la entidad cliente que analiza la factibilidad de la migración hacia 
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FOSS. 


Dicho informe persigue el objetivo de comunicar a los principales interesados el estado 
inicial de la entidad así como el potencial de éxito del proyecto de migración que se valora 
comenzar. Debe documentar entre otros elementos el alcance propuesto para la migración, 
los principales riesgos y restricciones del proyecto, así como las acciones de capacitación, 


soporte y sensibilización a realizar. 


Un elemento que no se debe obviar durante el desarrollo del Informe de diagnóstico es la 
sugerencia de programas informáticos que pudieran mejorar los procesos de la institución, 
así como la recomendación de apertura de proyectos para portar o desarrollar nuevamente 


las aplicaciones que no pudieron ser migradas por falta de alternativas libres. 


En sentido general el documento debe describir de forma detallada todas las soluciones 
tecnológicas, de entrenamiento, y soporte que serán implementadas durante la migración a 


tecnologías de software libre y código abierto propuesta. 
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Capítulo 3: Ejecución de la migración 


La ejecución de la migración es la etapa que marcará la eliminación o disminución del uso 
del software privativo en la institución, la misma estará marcada por tres hitos importantes: 
la elaboración del plan de migración, la migración de los servicios telemáticos y del escritorio 


de los usuarios. 


Planificación de la migración 


Una vez aprobada la viabilidad del proceso de migración por la dirección de la institución, se 
procederá a la planificación del proceso de ejecución, la cual será recogida en el plan de 


migración institucional. 


El plan de migración contendrá las fechas de ejecución de todas las actividades definidas 
por los especialistas y que fueron plasmadas en el informe de consultoría dentro de los 


aspectos relacionados con capacitación, soporte, sensibilización e implantación. 


Es importante establecer un cronograma general donde se encuentren todas las actividades 
para evitar solapamiento entre ellas. Para la elaboración del plan deben tenerse en cuenta 


todas las áreas de la gestión de proyectos definidas en el PMBOK [8]. 


Inicio del servicio de soporte técnico 


Por la importancia que tiene el soporte en el futuro funcionamiento de los sistemas, es 
importante cumplir con lo recomendado por el equipo de migración y montar toda la 


infraestructura para que comience a funcionar antes de iniciar la migración de los sistemas. 
Migración de los servicios telemáticos 


Capacitación del personal de redes de la institución 


Complementando la importancia de la formación para el proceso de migración, la primera 
actividad a realizar durante la migración de los servicios telemáticos será el entrenamiento 


de los administradores de red. Dicha capacitación deberá estar enfocada en las técnicas y 
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herramientas existentes para la administración y migración de los servicios telemáticos, 
haciendo especial énfasis en los que se implementarán en la institución de acuerdo al plan 


de migración establecido. 


Es importante en esta etapa lograr la motivación de los especialistas en servicios 
telemáticos de la institución, de forma tal que ellos sean partícipes directos en el proceso de 
conjunto con el especialista del equipo de migración. Una buena preparación en los 
responsables de la administración de los servicios minimizará el número de incidencias de 


soporte asociadas en el futuro. 


Montaje de un escenario de pruebas basado en el escenario origen 


Una vez entrenados los administradores, lo próximo es probar si efectivamente es posible 
migrar todos los servicios y sus configuraciones, tarea que debe ejecutarse mediante una 


serie de pruebas pilotos en un servidor u ordenador ajeno al entorno de producción. 


Si el proceso de pruebas de migración no tiene éxito entonces debe procederse a montar 
manualmente en el nuevo sistema las configuraciones necesarias, una vez que se haya 
terminado de recrear el entorno real en el de pruebas y verificar que todo funciona como se 
esperaba, entonces hay que realizar una prueba de operatividad con los sistemas de la 


institución. 


Este proceso debe realizarse con extrema responsabilidad y teniendo en cuenta todos los 
elementos del escenario origen. El resultado final debe ser una copia exacta que reflejará 


cómo van a quedar los servicios telemáticos en el escenario destino. 


Puede ser útil que algunos usuarios de la entidad interactúen con el nuevo sistema aunque 


no sea en su entorno formal de trabajo para recoger la opinión y criterios de los mismos. 


Al concluir esta actividad debe realizarse una evaluación con elementos concretos donde se 
compare la solución privativa existente y lo que ofrece la nueva solución; los servicios, el 
rendimiento, la facilidad de uso para los usuarios finales y la compatibilidad son elementos 


claves a tener en cuenta en la comparativa. 
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Realizar copia de seguridad a los sistemas en el escenario origen 


Una vez culminado el piloto y con pruebas reales de que la migración y/o montaje del nuevo 
entorno funciona de manera correcta, sólo resta realizar la migración de los servidores 


reales, pero antes es altamente recomendado realizar salvas de seguridad a los mismos. 


Las salvas incluyen todo lo que esté involucrado con garantizar la restauración del servicio 
en caso de que algo no fluya como se espera en el entorno de producción montado. Si se 
emplea algún entorno de virtualización en el escenario origen es recomendado guardar 
todas las máquinas virtuales de los servicios brindados. En caso contrario se recomienda 


guardar los discos duros donde están los servicios privativos instalados. 


Ejecutar la migración de los servicios 


Una vez esté todo preparado en la institución y el equipo de migración está seguro de que 
todos los pasos realizados con anterioridad se han cumplido satisfactoriamente, se puede 


proceder con la migración de los servicios privativos de la empresa. 


Este será el primer hito de cambio de tecnología en la institución, por lo que se deberá 


prestar atención al proceso y la reacción que puede causar en los usuarios involucrados. 
Para la migración de los sistemas pueden seguirse dos posibles rutas. 
Ruta 1 (recomendada) 


Esta ruta es la más recomendada, pues permite tener funcionando el dominio privativo en la 
medida que se realiza el montaje del dominio FOSS y se verifica el correcto funcionamiento 
de la infraestructura de manera paralela. Al finalizar el montaje del dominio FOSS se apaga 


el privativo y se comienza a usar el libre. 
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Escenario origen Ejecución de la migración : Escenario destino 


Figura 7: Esquema de la ruta 1 para migrar los servicios telemáticos. 
Ventajas: 


+ Los especialistas cuentan con más tiempo para montar la infraestructura de 


servicios. 
+. Disminuye el riesgo de errores. 
+ No se detienen los servicios institucionales. 


+ La infraestructura privativa permanece funcional pero apagada al finalizar la 


migración. Si se necesitara una regresión basta con reconectarla. 


Desventajas: 
+ Es más costosa económicamente. 
Ruta 2 


El objetivo es el mismo, sin embargo se debe retirar el servicio de conectividad durante el 


tiempo que dure la migración e instalación de la nueva infraestructura FOSS. 
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Ventajas: 


+ Es menos costoso. 


Desventajas: 


+ Aumenta la posibilidad de ocurrencia de errores. (Menor tiempo para ejecutar la 


migración) 


+ La institución deberá permanecer sin servicios por un período de tiempo 


determinado. 


Si por razones económicas fuera seleccionada la Ruta 2 para el proceso, se recomienda 
cambiar los discos duros, preservar los existentes y en los nuevos instalar la nueva 
infraestructura FOSS. En este caso la migración debe realizarse fuera del horario de trabajo 
o en un momento de baja demanda de los servicios. Los usuarios deben ser informados del 


período de tiempo que estarán los servicios apagados. 


La reutilización de una plataforma de virtualización existente o la instalación de una nueva 
es una excelente opción, pues una vez montada y operativa la infraestructura FOSS se 
puede realizar un backup de los servidores para en caso de emergencia volver a poner los 


servicios en operación. 


Medidas de seguridad informáticas a nivel de aplicación 


De acuerdo con lo exigido por la institución en cuestión, pueden implantarse medidas 
lógicas de seguridad a través de un cortafuegos implementando alguna de las arquitecturas 
existentes. Puede sumarse a ello la instalación de sistemas de detección de intrusos en 


alguna de sus variantes. 


Posterior a la implementación de las medidas de seguridad en la institución debe verificarse 
que los usuarios autorizados tengan el acceso requerido a los recursos. Se recomienda usar 
las aplicaciones disponibles en el Anexo 6: Aplicaciones libres alternativas al software 
privativo (Servidores) para el uso de cortafuegos e IDS?. 


2 IDS: Dispositivo o aplicación que monitorea la red o el sistema para prevenir actividades 
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Monitoreo de servicios 


Es clave para conocer en todo momento el estado de la infraestructura de servicios 
monitorearlos de forma automatizada, de forma tal que se pueden tomar acciones rápidas 


ante fallas o irregularidades en los sistemas. 


Es importante a la medida que se instalen los sistemas en la infraestructura FOSS añadirlos 
a la plataforma centralizada de monitorización. Similar al caso anterior el Anexo 6: 
Aplicaciones libres alternativas al software privativo (Servidores) muestra la solución 


propuesta para el monitoreo. 


Definición de la política de salvas 


Una vez migrados los servicios, y establecidas todas las configuraciones para obtener en el 
servidor niveles de disponibilidad, optimización, estabilidad y seguridad aceptables se 


establecerá una política de salvas entre servidores. 


El equipo de migración en conjunto con los especialistas que se encargarán de administrar 
los servidores deben definir los servicios que estarán disponibles en caso de que los 
principales dejen de funcionar, así como los lugares donde se distribuirá la información entre 
los diferentes puntos de la red y una vez definidas estas políticas, incluyendo la periodicidad 


y estrategia (total, incremental, diferencial) de las salvas se procederá a su ejecución. 


Es recomendado agregar al plan de recuperación ante desastres de la institución todas las 


políticas y medidas relacionadas con la salva y restauración de la información. 


El proceso de salvas y restauración puede realizarse de manera automatizada con las 
herramientas propuestas en el Anexo 6: Aplicaciones libres alternativas al software privativo 


(Servidores). 


maliciosas o violación de políticas, produciendo reportes hacia una estación de administración. 
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Migración del escritorio 


Informar a los usuarios 


Uno de los elementos claves del éxito consiste en no engañar a los usuarios sobre lo que se 
está realizando en materia de migración. Los mismos deben ser conscientes en todo 


momento de las actividades para lograr su máxima colaboración en las mismas. 


El plan de migración debe ser de conocimiento público, así como deben circularse por las 
diferentes vías y espacios (correo electrónico, reuniones, charlas, entre otras) las 


actividades que se irán realizando en cada momento, instando a los usuarios a colaborar. 


Instalar aplicaciones libres sobre el entorno privativo 


Es fundamental la instalación de aplicaciones libres sobre el entorno privativo, ello permitirá 
a los usuarios conocer en el sistema operativo que ya dominan las herramientas que en el 
futuro próximo usarán sobre el sistema operativo libre. Dicho proceso de instalación hasta el 
momento no supone la desinstalación de la herramienta privativa, ambas deben convivir en 
el sistema. A medida que los usuarios se capaciten deberán ir usando las aplicaciones 
libres. Una iniciativa para lograr este último aspecto puede ser el comienzo de la circulación 
de los documentos ofimáticos en formato de documento abierto (ODF*) [9], obligando a los 


usuarios involuntariamente a usar LibreOffice. 


Eliminar en este paso la aplicación privativa trae como consecuencia rechazo y bajo 
rendimiento en la productividad de los usuarios. Las herramientas a instalar deberán estar 
reflejadas en el plan de migración previamente elaborado. 


Capacitar a los usuarios 


Siguiendo la planificación definida en el plan de migración, debe ejecutarse seguidamente el 
entrenamiento de los usuarios en el manejo de las aplicaciones libres sobre Microsoft 


Windows. 


3  ODF: Open Document Format, ISO/IEC 26300:2006 
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Al culminar esta actividad debe existir plena seguridad de que los usuarios dominan las 
herramientas en las que fueron capacitados y que fueron solucionadas las deficiencias 
detectadas en el proceso de diagnóstico. La evaluación del proceso y su posterior 


certificación son claves para garantizarlo. 


Una vez los usuarios dominen las aplicaciones libres correctamente, resulta de gran apoyo a 
la migración que el director emita una comunicación indicando la obligatoriedad de usar 
formatos de archivos estándares. La Tabla 5 muestra los formatos de archivos abiertos para 


las aplicaciones más comunes. 


Tabla 5: Formatos libres más empleados 


Tipo de aplicación Formato Significado 

Procesador de textos ODT Open document text 

Editor de presentaciones ODP Open document presentation 
Hoja de cálculos ODS Open document spreadsheet 
Base de datos personales ODB Open document base 
Gráficos vectoriales sencillos ODG Open document graphics 
Editor de imágenes de mapa de xCF Experimental Computing 

bits Format 

Visor de imágenes de mapa de PNG Portable Network Graphics 
bits 

Editor de gráficos vectoriales svG Scalar Vector Graphics 
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Migrar los archivos existentes 


Las ventajas de hacer uso de los formatos de archivos en el sector público [10] y la amplia 
compatibilidad de las aplicaciones libres con los mismos, conlleva la realización de una 


migración de todos los archivos de documentos de la institución hacia el estándar ODF. 


La migración puede realizarse de manera semi-automtizada, usando las herramientas 


ODFCorverter [11], JODConverter [12] y el convertidor de documentos de LibreOffice. 


En dicho cambio de formato pueden estar involucrados los formatos de archivos de 
documentos, hojas de cálculos, presentaciones digitales y bases de datos personales. Se 
debe prestar especial atención a los archivos de este tipo que incorporan macros. En las 


bases de datos solo es posible migrar de manera automatizada las tablas y sus datos. 


Desinstalar aplicaciones privativas 


Los usuarios deberán trabajar sobre el entorno privativo con herramientas libres por un 
período de tiempo. No existe una cantidad de días definidos para ello, es decisión de los 
especialistas que estén ejecutando la actividad decidir qué plazo de tiempo se usará 


software libre sobre Microsoft Windows o en el sistema operativo privativo usado. 


Al realizar esta tarea, debe verificarse que la actividad relacionada con la migración de los 
servicios telemáticos (Ver epígrafe: Ejecutar la migración de los servicios) haya concluido 
para pasar a la siguiente, ello responde a la necesidad de instalar sobre Microsoft Windows 
las aplicaciones libres que permitirán hacer uso de esos servicios (Ejemplo: Cliente de 
correo electrónico y mensajería instantánea). Debe ejecutarse sobre el entorno privativo un 


entrenamiento a los usuarios en el empleo de estas aplicaciones. 


Migrar el sistema operativo base 


La migración del sistema operativo es la actividad que marcará la sustitución de Microsoft 


Windows y permitirá instalar un sistema operativo GNU/Linux u otro libre. El proceso de 
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cambiar el sistema requiere: 


1. Realizar un diagnóstico para detectar los archivos importantes existentes en cada 


ordenador de los usuarios que deban ser resguardados. 


2. Realizar una salva de respaldo de dichos archivos en otra computadora o en un 


servidor centralizado. 
3. Formatear e instalar el nuevo sistema. 


4. Configurar el nuevo sistema, manteniendo la configuración de la red (número de IP, 
recursos compartidos). Esta información es extraída del diagnóstico realizado en la 


etapa de preparación de la migración. 
5. Restaurar los archivos guardados en el paso 2. 


6. Realizar las configuraciones y ajustes necesarios para el correcto funcionamiento del 
sistema, por ejemplo: montar particiones de forma permanente, configurar el cliente 


de navegación web, cliente de correo y mensajería instantánea entre otras. 


Llegado este punto, es importante tener certeza de que los usuarios dominan correctamente 


el trabajo con el sistema operativo GNU/Linux instalado. 
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Anexo 1: Información necesaria del software instalado. 


Elemento Descripción 

Nombre: Nombre del software en cuestión 
Descripción: Descripción del software 
Versión: Versión que está siendo usada 


Anexo 2: Información necesario del hardware de las computadoras. 


Procesador 

Tipo: <Tipo del procesador, ejemplo : Intel Core Duo T6 570> 
Velocidad: <Velocidad en MHz> 

Cantidad: <Cantidad de procesadores> 

Disco duro 

Fabricante: <Fabricante del disco, ejemplo Seagate, Hitachi> 
Modelo: <Modelo del disco duro, ejemplo: ST9250315AS> 

Tipo: <Tipo de disco, IDE/SATA> 

Capacidad: <Espacio de almacenamiento del disco en MB> 
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Tarjeta de vídeo 
Fabricante: <Fabricante de la tarjeta, ejemplo ATI, NVidia> 
Chipset: <Chipset de vídeo, ejemplo: Intel 82915G Express> 
Memoria: <Memoria de vídeo usada, ejemplo: 256Mb> 
Resolución: <Resolución de vídeo, ejemplo: 800x600> 
Tarjeta de sonido 
Fabricante: <Fabricante de la tarjeta, ejemplo: Genius> 
Modelo: <Modelo de la tarjeta> 
Tarjeta de red 
Tipo: <Tipo de la tarjeta de red : Inalámbrica/Cableada > 
Marca: <Marca de la tarjeta de red> 
Modelo: <Modelo de la marca en cuestión> 


Información de la conexión? 


Dirección IP: <Número IP de la computadora> 


Máscara de red: <Máscara de la red> 


Puerta de enlace: —<Puerta de enlace del sistema> 


Servidor DNS: <Servidor DNS de la red> 


4 La información de la conexión será usada para una vez migrada la institución poder mantener los 


números IP de la red en el mismo estado en que se encontraban. 
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BIOS 
Número de serie: — <Identificador único del BIOS> 
Fabricante: <Empresa que fabricó el BIOS, ejemplo: Lenovo> 
Modelo: <Modelo del BIOS, ejemplo: 2713AA3> 
Versión: <Identificador de la versión, ejemplo: 7YET79W (3.09)> 


Anexo 3: Información necesaria de cada aplicación propia de la 


institución 
Elemento Descripción 
Nombre: Nombre del software en cuestión 
Descripción: Descripción del software 
Tecnologías utilizadas: Tecnologías utilizadas para el desarrollo 
Lenguajes utilizados: Lenguajes de programación utilizados en el desarrollo 
Disponibilidad del CF: Disponible o no el código fuente 
Nivel de criticidad: Alto / Medio / Bajo 


Anexo 4: Información a recopilar por cada dispositivo externo. 


Elemento Descripción 


Tipo de dispositivo: — (Impresora, Scanner, etc.) 


Fabricante: Fabricante del dispositivo 
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Marca: 


Marca del dispositivo 


Modelo: 


Modelo del dispositivo 


Anexo 5: Aplicaciones 


(Escritorio) 


libres alternativas al 


software privativo 


Categoría: Oficina 


Software privativo Perfil Bajo Perfil Medio/Alto Observaciones 

Microsoft Office Word Abiword LibreOffice Writer Procesador de textos 
Microsoft Office Excel Gnumeric LibreOffice Cale Hojas de cálculo 
Microsoft Office P.Point |NA LibreOffice Impress Presentaciones 

Microsoft Office Access |NA LibreOffice Base BD personales 

Microsoft Office Project |OpenProject OpenProject Planificación de proyectos 
Microsoft Office Visio Dia LibreOffice Draw Gráficos vectoriales 
Adobe Reader Xpf Evince Visor de PDF 

Editor PDF (C) NA LibreOffice Draw Extensión paf-import 
Categoría: Internet 

Software privativo Perfil Bajo Perfil Medio/Alto Observaciones 

Internet Explorer Midori Firefox / Chrome Navegador web 

Pandion / Instant Msg Pidgin Pidgin / Empathy Mensajería instantánea 
Microsoft Outlook Claws Mail ThunderBird / KMail Cliente de correo electrónico 
Cliente FTP (C) gFTP Filezilla Cliente FTP 

Cliente SSH (C) Putty Putty Cliente SSH 

Remote Desktop TsClient TsClient Acceso remoto 
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Admin. Cortafuegos 


Gufw 


Firestarter 


Cortafuegos 


Cliente torrent (C) 


Transmission 


Deluge 


Cliente Torrent 


Cliente Twitter (C) 


Mitter 


TweetDeck / Chogok 


Cliente Twitter 


Categoría: Sonido y vídeo 


Software privativo Perfil Bajo Perfil Medio/Alto Observaciones 

Winamp Audacious Audacious Reproductor de audio simple 

Windows Media Player | SMPlayer VLC / Kaffeine Reproductor de vídeo 

Windows Media Player | Rhythmbox Rhythmbox/Amarok Librería de música 

SoundForge Audacity Audacity Editor de audio 

MovieMaker NA Kdenlive/OpenShot Editor personal de vídeo 

Premier NA Cinellera Editor profesional de vídeo 

Music Creator (C) NA Hydrogen / LMMS Creador de música 

Format Factory Fímepg (CL) Hyper V. Converter Convertidor de vídeo 

DVD Authoring (C) NA ManDVD / Q'DVD Autoría de DVD 

Nero Tools XfBurn Brasero / K3b Quemador de CD/DVD 

Categoría: Diseño 

Software privativo Perfil Bajo Perfil Medio/Alto Observaciones 

Image Viewer GPickView E0G Visor de imágenes 

Picasa Shotwell Shotwell Organizador de imágenes 

Microsoft Paint Mtpaint KPaint Editor de mapas de bit 

Photoshop Gimp Gimp Editor profesional de 
mapas de bit 
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Corel Draw Inkscape Inkscape Editor vectorial 
3DMax NA Blender Editor 3D 
Layout Scribus Scribus Maquetado 
Autocad NA BRLCAD / FreeCAD* Herramienta CAD 
Image Converter (C) NA Converseen Convertidor de imágenes 
* Esta herramienta debe ser validada por especialistas. 
Categoría: Desarrollo 
Software privativo Perfil Bajo Perfil Medio/Alto Observaciones 
Microsoft Visual Studio Sublime Text Monodevelop Desarrollo .NET 
Microsoft VS (C++) Sublime Text Monodevelop Desarrollo C++ 
Java Development (C) Sublime Text Eclipse / NetBeans* Desarrollo Java 
PHP Development (C) Sublime Text Eclipse / Netbeans * Desarrollo PHP 
Python Development (C) | Sublime Text Eclipse + PyDev Desarrollo Python 
C++ Development (C) Sublime Text QtCreator Desarrollo C++ 
HTML5, CSS3 (C) Sublime Text Aptana Studio IDE HTML, CSS 
MySQL Admin (C) Phpmyadmin MySQL Workbench Gestor de bases de datos 
PostgreSQL Admin (C) Pgadmin Pgadmin Gestor de bases de datos 
SVN Client (C) Rapidsvn Rapidsvn / Kdesvn Cliente SVN 
Git Client (C) Git (CLI) GitEye Cliente Git 


* Aplicaciones muy parecidas, es cuestión de gusto personal. 
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(Servidores) 


libres alternativas al 


Anexos 


software privativo 


Software privativo 


Alternativa libre 


Nombre de 

servicio a IA E a medianas 
organizaciones organizaciones 

Proxy ISA Server/Kerio Squid Squid 

DHCP DHCP Windows Server ISC-DHCP-Server ISC-DHCP-Server 

DNS DNS Windows Server Bind9 Bind9 

LDAP Active Directory Samba4/OpenLDAP  |Samba4/OpenLDAP 

Jabber Openfire u otro Openfire Openfire/jabberd 

FTP FTP Windows Server u otro  |VSFTP VSFTP 

Web 11S, Apache Apache/nGinx Apache/nGinx 

Correo Exchange, Mdaemon Zimbra Zimbra/lredmail 


Virtualización 


ESX de Vmware 


KVM / Proxmox 


KVM 


Backup - Bacula/Amanda Bacula/Amanda 
Monitoreo - Nagios/Zabbix Nagios/Zabbix 
Firewall - IPtables IPtables 

IDS - Snort Snort 
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